View AN720_4826732.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

rev. 0.1 9/12 copyright ? 2012 by silicon laboratories AN720 AN720 p recision 32? o ptimization c onsiderations for c ode s ize and s peed 1. introduction the code size and execution speed of a 32-bit mcu proj ect can vary greatly depending on the way the code is written, the toolchain libraries used, and the compiler and linker options. this document addresses how to determine what portions of code are taking extra space or time and ways to optimize for space or speed for different tool chains, incl uding gcc redlib and newlib (precision32 ide) and keil. 2. key points the key topics of this document are: ?? how to determine what portions of th e project are taking the most space ?? ways to benchmark code execution speed ?? common strategies to reduce code size or improve execution speed ?? code startup time and ways to reduce it 3. using coremark? as a speed benchmark coremark is a standard code base t hat can be ported to various processo rs to provide a speed benchmark. the coremark software provides a score that rates how fast the core and code is, providing a relative comparison between various toolchain options and settings. the corema rk software package cannot be modified except for device-specific information in the portme files. for modes that do not support printf (nohosting libraries), the results were calculated using the value of the variable in code. see the coremark we bsite for more information on the test and score reporting requirements ( www.coremark.org ). 4. non-toolchain considerations the coding style and technique can have a grea t effect on the overall size of the project. 4.1. coding techniques there are many ways coding technique can affect code size, including library calls, inline code or data, or code optimizations made for global variables or pointers. for more information on writing c code for ar m architectures, see the following resources: ?? eetimes - energy efficient c code for arm devices by chris shore: http://www.eetimes.com/design/ embedded/4210470/efficient- c-code-for-arm-devices ?? compiler coding practices - arm : http://infocenter .arm.com/help/index.jsp?topic=/ com.arm.doc.dui0472c/cjafjcfg.html these guidelines will largely apply regardless of the co mpiler used for the project. 4.2. number of function parameters functions with either keil or gcc can have as many parame ters as desired. in general, the first four parameters are passed to the function efficiently using registers. any additional paramete rs beyond four must be moved on or off the stack, which results in extra code size for each additional parameter and ex tra time to execute those instructions. if possible, keeping functions to no more than four parameters can help reduce code size and execution time.
AN720 2 rev. 0.1 4.3. alignment in most cases, cortex-m3 linkers place code in memory ef ficiently. in some projects, however, the alignment of functions and code can be carefully managed manually to reduce code size or change code execution speed. for example, if two functions in the same file call each other, but one ends up in flash and one ends up in ram, the compiler may need to place extra code to perform a long jump and take longer to execute that jump. if needed, functions and variables can be explicitly located using sc atterfiles and linker flags. more informat ion on linker scripts and scatterfiles can be found on the code red (http://support.code-red-tech.com/coderedwiki/ ownlinkscripts) and arm websites (http://infocenter .arm.com/help/index.jsp?to pic=/com.arm.doc.kui0101a/ armlink_babddhbf.htm). 4.4. ram size the ram size of a project can be just as important as th e code size. in particular, the default configurations for sim3xxxx projects place the stack at the top of memory growing down and the heap at the end of program data growing up. if too much of the ram is used by program data, then the stack and heap may collide, leading to difficult debugging issues in run-time. projects shou ld always leave enough ram space to accommodate the function-calling depth of the code. 4.5. sim3xxxx core and flash access speed at the maximum device ahb speed, an sim3xxxx device reading flash every pipeline cycle may violate the maximum flash access speed. to compen sate for this, the flashctrl module has controls to reduce the flash access speed (spmd and rdsen). depending on the code density and make-up (i.e., 16-bit or 32-bit instructions), this may lead to stalls in the core before the next instruct ions can be fetched from flash. executing at high speeds with strings of 16-bit instruct ions may yield the fastest core operation. 4.6. sim3xxxx core and the dir ect memory access (dma) module on sim3xxxx devices, the core and the dma can access multiple ahb slaves at the same time without any performance degradation. if the core and dma access the same ahb slave at the same time (i.e., ram), then the ahb has priority-based arbitration in the following precedence: 1. core data fetch 2. dma 3. core instruction fetch if multiple dma channels are active at the same time and accessing the same memory areas as the core, this could lead to a reduction in core execution speed.
AN720 rev. 0.1 3 5. precision32 ide (redlib and newlib) this section discusses ways to optimize projects using the precision32 ide and both redlib an d newlib libraries. the precision32 gcc tools used for the code size and ex ecution speed testing discussed in this document are arm/embedded-4_6-branch revision 182083 ( http://gcc.gnu.org/svn/gcc/branc hes/arm/embedded-4_6-branch/ ) with newlib v1.19 and redlib v2 (pre cision32 ide v4.2.1 [build 73]). 5.1. reading the map file the first step in the code size optimization process is to analyze the project map file and determine what portions of code take the most space. the map file is an output of the linker that shows the si ze of each function and variable and their positions in memory. this map file is located in the build files for a project. in addition to the functions, the ma p file includes information on variab les and other symbols, including unused functions that are removed. for a precision32 ide debug build, the map file is located in the project?s debug directory. figure 1 shows an excerpt of the sim3u1xx_blinky redlib debug example map file. for each function in the project, the map file lists the starting address and the length. for example, the my_rtc_alarm0_handler function starts at address 0x0000_04d4 and occupies 0x70 bytes of memory. figure 1. sim3u1xx_blinky precision32 debug map file example 5.2. determining a project?s code size each project?s library and function usage is different. a nalyzing the project?s makeup can help determine the most effective way to reduce code space. all precision32 sdk projects automatically output the code and ram size after a build. to modify this output in the precision32 ide: 1. right-click on the project_name in the project explorer view. 2. select properties . 3. in the c/c++ build ? settings ? build steps tab, remove or add the following in the post-build steps ? command box: arm-none-eabi-size "${buildartifactfilename}" after building the si32hal 1.0.1 sim3u1xx_blinky example, the ide outputs: text data bss dec hex 13312 4 344 13660 355c
AN720 4 rev. 0.1 the areas of memory are: ?? text : code and read-only memory in decimal ?? data : read-write data in decimal ?? bss : zero-initialized data in decimal ?? dec : total of text, data, and bss in decimal ?? hex : total of text, data, and bss in hex more information about the size tool can be found on the code red website ( http://support.code-red-tech.com/ coderedwiki/flashramsize ). figure 2. automatically reporting project size on project build in precision32
AN720 rev. 0.1 5 5.3. toolchain library usage some toolchains have multiple libraries or settings that can change the size or execution speed of code. the precision32 tools have six options: ?? newlib (standard gcc) with no standard i/o ?? newlib (standard gcc) wit h nohosting standard i/o ?? newlib (standard gcc) with semihosting standard i/o ?? redlib (gcc) with no standard i/o ?? redlib (gcc) with nohosting standard i/o ?? redlib (gcc) with semihosting standard i/o the semihosting libraries have additional hooks to enable a pr oject to send debugging information to an ide running on a pc. the nohosting libraries have this additional capability removed. the none versions of the toolchains have no standard i /o capability (i.e., no printf()). for some example projects (like si32hal 1.0.1 sim3u1xx_blinky ), the compile-time library can be modified by opening the mylinkeroptions_p32.ld file in the project directory and changing the uncommented line. figure 3. using the mylinkeroptions_p32.ld file to select the project library the four lines in the file correspond to a library: ?? group(libgcc.a libc.a libm.a lib cr_newlib_nohost.a) (line 4) : newlib nohosting ?? group(libgca.a libc.a libm.a lib cr_newlib_semihost.a) (line 5) : newlib semihosting ?? group(libcr_semihost.a libcr_c.a libcr_eabihelpers.a) (line 6) : redlib semihosting ?? group(libcr_nohost.a libcr_c.a libcr_eabihelpers.a) (line 7) : redlib nohosting the none libraries do not have corresponding entries in this file. add these lines to add support for none: ?? group(libgcc.a libc.a libm.a) : newlib none ?? group(libcr_c.a libcr_eabihelpers.a) : redlib none after setting the mylinkeroptions_p32.ld file to the corr ect setting, set the ide to the same library using these steps: 1. left-click on the project_name in the project explorer view. 2. select properties . 3. click on c/c++ build ? settings ? tool settings tab ? mcu linker ? target and select the desired library from the use c library drop-down menu. figure 4 shows this dialog in the precision32 ide. 4. clean and build the project. appbuilder projects do not have a mylinkeroptions_p32.ld file and can use the quickstart view setting only.
AN720 6 rev. 0.1 figure 4. using the precision32 ide to select the project library using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 1 and table 2 show the relative debug build sizes with the different toolchain library options. table 3 shows the debug build sizes for coremark, and table 4 shows the relative coremark speed scores for each of these library options. for the newlib and redlib none libraries, see ?5.4. function library usage?. table 1. precision32 toolchain library usage comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting 35564 2248 124 newlib nohosting 34864 2248 68 newlib none n/a (requires printf() removal) redlib semihosting 13080 4 344 redlib nohosting 13136 4 344 redlib none n/a (requires printf() removal)
AN720 rev. 0.1 7 table 2. precision32 toolchain library usage comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting 108844 6944 11904 newlib nohosting 108144 6944 11848 newlib none n/a (requires printf() removal) redlib semihosting 76176 4704 12124 redlib nohosting 76120 4704 12124 redlib none n/a (requires printf() removal) table 3. precision32 toolchain library usage comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting 46900 2352 2140 newlib nohosting 46208 2352 2084 newlib none n/a (requires printf() removal) redlib semihosting 24400 112 2360 redlib nohosting 24344 112 2360 redlib none n/a (requires printf() removal) table 4. precision32 toolchain library usage comparison?coremark debug speed library coremark score newlib semihosting coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib nohosting coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib none n/a (requires printf() removal) redlib semihosting coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib none n/a (requires printf() removal)
AN720 8 rev. 0.1 5.4. function library usage function libraries such as floating point math and printf() can significantly increase the size of a project. if a project is constrained by size, a careful analysis of the usa ge of these large libraries may be required. for example, floating point can often be approximated well by fixe d point math, eliminating the need for the floating point libraries. the printf() library is often needed by projects for debugging or release code. if printf() is used for debugging purposes, using a defined symbol in the project to remove printf() when compiling a release build can dramatically reduce the size of a project. to define a symbol to di fferentiate between a debug pr oject and a release project, see ? contact information?. the code can then use #ifdef ... #endif preprocessor statements to remove debugging code or printf() calls. the removal of debugging printf() statements can dramatically reduce the co de size of a project. a simple way to do this is to redefine the printf function at the top of the file containing the printf() calls using the following statement: #define printf(args...) for si32library examples such as demo_si32usbaudio , define the statement at the top of mybuildoptions.h to remove all calls to printf() with higher optimization settings. additionally, reduce the code size footprint by disabling logging in mybuildoptions.h: #define si32buildoption_enable_logging 0 this method preserves the printf() statements for later use, if needed. the printf() define can also be encapsulated with preprocessor #if statements to automatically include th is define when building with a release configuration. when removing printf() for use with newlib none or re dlib none, all references to printf() and stdio.h must be commented out of the project. the none libraries cannot be used with si32library projects. to verify that all instances of printf() have been removed, search the map file for the project for the printf library. in the sim3u1xx_blinky example, this means adding the statement to both the main.c and gcpu.c files. instead of using standard printf() , which can have a high library cost, use integer-only print functions like iprintf() for newlib projects. for redlib projects in the precision32 id e, create a define cr_integer_printf in the project properties to force an integer-only version of printf() . for instances of printf() with a fixed-string, using puts() can dramatically redu ce code size. more information about redlib and printf() can be found on the code red website: http://support.code-red- tech.com/coderedwiki/usingprintf. if a project does not use any standard i/o functions, use the redlib or newlib none toolchain option to reduce code size as discussed in ?6.3. toolchain library usage?. using the sim3u1xx_blinky default example in the si32hal 1.0.1 so ftware package, table 5 shows the relative build sizes with the different printf() settings. the demo_si32usbaudio comparison is not included since printf() removal requires higher optimization se ttings or code modifications. this section also does not include the coremark tests since printf is not part of the coremark benchmark.
AN720 rev. 0.1 9 table 5. precision32 printf() comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting with printf 35564 2248 124 newlib nohosting with printf 34864 2248 68 newlib nohosting with integer printf (iprintf) 19800 2248 68 newlib nohosting with puts instead of printf 8784 2120 68 newlib nohosting wi thout printf 2064 4 8 newlib none with all calls to stdio and printf removed 2064 4 8 redlib semihosting with printf 12880 4 344 redlib nohosting with printf 12824 4 344 redlib nohosting with integer printf ( cr_integer_printf) 8111 4 344 redlib nohosting with puts instead of printf 4004 4 344 redlib nohosting without printf 3868 4 344 redlib none with all calls to stdio and printf removed 2068 4 8
AN720 10 rev. 0.1 5.5. toolchain op timization settings in addition to the library types, each toolchain has multiple optimization settings that can affect the resulting code size. with the precision32 toolchain, code op timization can be set by following these steps: 1. right-click on the project_name in the project explorer view. 2. select properties . 3. in the c/c++ build ? settings ? tool settings tab ? mcu c compiler ? optimization options, select the desired optimization level. figure 5 shows the optimization settings for the precision32 ide. level -o0 has the least optimization, while -o3 has the most optimization . an additional flag ( -os ) allows for specific op timization for code size. more information on the optimization levels can be found on the code red website (http://support.code-red- tech.com/coderedwiki/compileroptimiz ation) and the gcc website (http:/ /gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/ optimize-options.html). de claring a variable as volatile will prevent the compiler from optimizing out the variable. figure 5. setting the project optimization in the precision32 ide the precision32 ide has two build conf igurations by default: debug and rel ease. these build configurations have predefined optimization levels ( none for debug, -o2 for release). to switch between the two configurations: 1. right-click on the project_name in the project explorer view. 2. select build configurations ? set active and select between debug and release .
AN720 rev. 0.1 11 figure 6. selecting the active build configuration in the precision32 ide to change the settings of any build configuration: 1. right-click on the project_name in the project explorer view. 2. select properties . 3. in the c/c++ build ? settings ? tool settings tab options, select the build configuration at the top and the desired build configuration options. using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 6 and table 7 show the relative debug build sizes wit h the different optimization level settings. table 8 shows the coremark debug build sizes, and table 9 lists the coremark speed scores for these optimization levels.
AN720 12 rev. 0.1 table 6. precision32 toolchain optimization comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib nohosting -o0 34864 2248 68 newlib nohosting -o1 34032 2248 68 newlib nohosting -o2 33960 2248 68 newlib nohosting -o3 33960 2248 68 newlib nohosting -os 33808 2248 68 redlib nohosting -o0 13080 4 344 redlib nohosting -o1 12056 4 344 redlib nohosting -o2 12096 4 344 redlib nohosting -o3 12096 4 344 redlib nohosting -os 11768 4 344 table 7. precision32 toolchain optimization comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib nohosting -o 0 108144 6944 11848 newlib nohosting -o1 84400 6944 11852 newlib nohosting -o2 83152 6944 11852 newlib nohosting -o3 85136 6944 11856 newlib nohosting -o s 76528 6928 11848 redlib nohosting -o0 76120 4704 12124 redlib nohosting -o1 52048 4700 12124 redlib nohosting -o2 50752 4700 12124 redlib nohosting -o3 52736 4700 12128 redlib nohosting -os 44128 4688 12120 table 8. precision32 toolchain optimization comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting -o0 46900 2352 2140 newlib semihosting -o1 41812 2256 2140 newlib semihosting -o2 42828 2256 2140 newlib semihosting -o3 45948 2256 2140 newlib semihosting -os 40284 2256 2140 redlib nohosting -o0 24344 112 2360 redlib nohosting -o1 19160 12 2360 redlib nohosting -o2 20176 12 2360 redlib nohosting -o3 23296 12 2360 redlib nohosting -os 17624 12 2360
AN720 rev. 0.1 13 table 9. precision32 toolchain optimization comparison?coremark debug speed library coremark score newlib semihosting -o0 coremark 1.0 : 36.478654 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib semihosting -o1 coremark 1.0 : 79.807436 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib semihosting -o2 coremark 1.0 : 107.984518 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib semihosting -o3 coremark 1.0 : 103.509985 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib semihosting -os coremark 1.0 : 87.64509 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting -o0 coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting -o1 coremark 1.0 : 79.998784 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting -o2 coremark 1.0 : 107.984518 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting -o3 coremark 1.0 : 103.509985 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting -os coremark 1.0 : 87.64509 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack
AN720 14 rev. 0.1 5.6. unused code removal each file in a project becomes an object that is included. in other words, if any functions in a file are used, then the entire file is included by default. this can become an i ssue for a project using the si32hal and only a few functions from each module. removed (unused) functions can be viewed in the map files for the projects. for precision32, the -ffunction-sections and -fdata-sections optimization flags place each function and data item into separate sections in the file be fore linking them into the project. this means the compiler can optimize out any unused functions. these flag s are present in example and appbuilder projects by default and should be configured on a file-by-file basis. to add or remove these options to a file: 1. right-click on the file_name in the project explorer view. 2. select properties . 3. in the c/c++ build ? settings ? tool settings tab ? mcu c compiler ? miscellaneous options, add or remove the -ffunction-sections and -fdata-sections flags after the -fno-builtin flag to the other flags text box. figure 7. modifying the remove unused code compiler flags in the precision32 ide these flags must be compiled with the --gc-sections linker command, which is enabled by default in the precision32 ide. it is recommended that this linker co mmand always remain enabled. these flags only have a benefit in some cases, and may cause larger code size and slower execution in some cases. using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 10 and table 11 show the relative debug build sizes with different unused code removal settings. for no unused code removal, the projects were compiled without -ffunction-sections and -fdata-sections and with --gc- sections . for the examples with unused code remo val, the projects were compiled with -ffunction-sections , - fdata-sections , and --gc-sections . table 12 shows the coremark build sizes, and table 13 shows the coremark scores for the different unused code removal settings.
AN720 rev. 0.1 15 table 10. precision32 unused code removal comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib nohosting with no unused code removal 35504 2248 68 newlib nohosting with unused code removal 35112 2248 68 redlib nohosting with no unused code removal 13472 4 344 redlib nohosting with unused code removal 13080 4 344 table 11. precision32 unused code removal comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib nohosting with no unused code removal 122424 7240 12116 newlib nohosting with unused code removal 108144 6944 11848 redlib nohosting with no unused code removal 90288 5000 12392 redlib nohosting with unused code removal 76120 4704 12124 table 12. precision32 unused code removal comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) newlib semihosting with no unused code removal 47188 2368 2140 newlib semihosting with unused code removal 46900 2352 2140 redlib nohosting with no unused code removal 24656 124 2360 redlib nohosting with unused code removal 24344 112 2360 table 13. precision32 unused code removal comparison?coremark debug speed library coremark score newlib semihosting with no unused code removal coremark 1.0 : 37.452232 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack newlib semihosting with unused code removal coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting with no unused code removal coremark 1.0 : 37.875848 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack redlib nohosting with unused code removal coremark 1.0 : 37.571643 / gcc4.6.2 20110921 (release) [arm/embedded-4_6- branch revision 182083] iterations=3000 / stack
AN720 16 rev. 0.1 5.7. reset sequence the speed of the reset sequence of a device can be an important factor, especially for devices like the sim3u1xx/ sim3c1xx that require a reset to exit the lowest power mode. after the hardware jumps to the reset vector and loads the stack pointer address, the core must initialize the memory of the device. this involves copying data fr om flash to ram an d zero-filling any zero-initialized segments. then, the reset code typically calls a system initialization functi on and jumps to main. this reset sequence may take different times based on t he library used with the project. the startup code should always be compiled with the fastest speed optimizati on to ensure it takes as little time as possible. the si32hal examples have a ~500 ms delay added to a pi n reset event to prevent code from switching to a non- existent clock source and disable the device . this delay can be removed by defining the si32haloption_disable_pin_reset_delay symbol in the project. to define a symbol in the precision32 ide: 1. right-click on the project_name in the project explorer view. 2. select properties . 3. in the c/c++ build ? settings ? tool settings tab ? mcu c compiler ? settings options, add or remove the symbol to the defined symbols (-d) area. figure 8. adding a project define symbol in the precision32 ide table 14 shows the reset time comparison for the toolchai n libraries using the fastest speed optimization on the start up code. this time was measured using the sim3u1xx_blinky example in debug mode from the fall of a port pin at the beginning of the reset irq ha ndler to the fall of a port pin at the beginning of main() on an oscilloscope. this test requires modification of the si32hal startup sequence file startup__p32.c .
AN720 rev. 0.1 17 table 14. precision32 toolchain library usage comparison?sim3u1xx_blinky debug reset sequence library reset time (s) newlib semihosting with printf() 242 newlib nohosting with printf() 236 newlib none with printf() removed 9.4 redlib semihosting with printf() 90 redlib nohosting with printf() 90 redlib none with printf() removed 9.4
AN720 18 rev. 0.1 6. arm/keil vision this section discusses ways to optimize projects using the keil or arm toolchain in the vision ide. the keil vision tools used for the code size and execution speed testing discussed in this document are version v4.1.0.894. 6.1. reading the map file the map file is an output of the linker that shows the si ze of each function and variable and their positions in memory. this map file is loca ted in the build files for a project. in addit ion to the functions, the map file includes information on variables and other symbols, in cluding unused functions that are removed. figure 9 shows an excerpt from the sim3u1xx_blinky map f ile from the keil toolchain. the functions are listed with a base address and size. in this case, the my_rtc_alarm0_handler is 50 bytes located at address 0x0000_03a5. figure 9. sim3u1xx_blinky vision map file example 6.2. determining a project?s code size the keil vision ide automatically displays the code size information at the end of a successful build. after building the si32hal 1.0.1 sim3u1xx_blinky example, the ide outputs: program size: code=1968 ro-data=296 rw-data=24 zi-data=1536 ".\build\blinkyapp.axf" - 0 error(s), 0 warning(s). the areas of memory are: ?? code : all program code in decimal ?? ro-data : read-only data located in flash in decimal ?? rw-data : read-write uninitialized data located in ram in decimal ?? zi-data : zero-initialized data lo cated in ram in decimal
AN720 rev. 0.1 19 6.3. toolchain library usage some toolchains have multiple libraries or settings th at can change the size or execution speed of code. the keil vision tools have two options: stan dard and microlib. to switch between the two: 1. right-click on the project_name in the project window and select options for target ?project_name? or go to project ? options for target ?project_name? . 2. select the target tab. 3. use the use microlib checkbox to select the library. figure 10 shows this dialog in the vision ide. figure 10. using the vision ide to select the project library using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 15 and table 16 show the relative debug build size s with the different toolchain library options. table 17 shows the debug build sizes for coremark, and table 18 shows the relative coremark speed scores for each of these library options. table 15. keil toolchain library usage comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision standard 2296 312 24 1632 vision microlib 2068 296 24 1536
AN720 20 rev. 0.1 table 16. keil toolchain library usage comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision standard 51176 4388 5196 18068 vision microlib 47264 3832 5208 17972 table 17. keil toolchain library usage comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision standard 13860 868 156 3632 vision microlib 11276 636 156 3536 table 18. keil toolchain library usage comparison?coremark debug speed library coremark score vision standard coremark 1.0 : 65.602324 /arm4.2 (edg gcc mode) iterations=3000/stack vision microlib coremark 1.0 : 69.402323 /arm4.2 (edg gcc mode) iterations=3000/stack
AN720 rev. 0.1 21 6.4. function library usage the removal of debugging printf() statements can dramatically reduce the co de size of a project. a simple way to do this is to redefine the printf function at the top of the file containing the printf() calls using the following statement: #define printf(args...) for si32library examples such as demo_si32usbaudio , define the statement at the top of mybuildoptions.h to remove all calls to printf() . additionally, reduce the footprint by disabling logging in mybuildoptions.h: #define si32buildoption_enable_logging 0 this method preserves the printf() statements for later use, if needed. the printf() define can also be encapsulated with preprocessor #if statements to automatically include th is define when building with a release configuration. to verify that all instances of printf() have been removed, search the map file for the project for the printf library. in the sim3u1xx_blinky example, this means adding the statement to both the main.c and gcpu.c files. using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 19 and table 20 show the relative build sizes with the different printf() settings. this section does not include the coremark tests since printf is not part of the coremark benchmark. table 19. keil printf() comp arison?sim3u1x x_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib with printf 2068 296 24 1536 vision microlib without printf 1392 296 12 1536 table 20. keil printf() comp arison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib with printf 47264 3832 5208 17972 vision microlib without printf 39760 4312 5196 17972
AN720 22 rev. 0.1 6.5. toolchain op timization settings in addition to the library types, each toolchain has multiple optimization settings that can affect the resulting code size. in keil vision, the optimization settings are set using the following steps: 1. right-click on the project_name in the project window and select options for target ?project_name? or go to project ? options for target ?project_name? . 2. select the c/c++ tab. 3. use the optimization drop-down menu to set the project optimization setting. figure 11 shows the optimization settings in the ide. the available options are: ?? level 0 : minimum optimization ?? level 1 : restricted optimization, removing inlin e functions and unused static functions ?? level 2 : high optimization ?? level 3 : maximum optimization with aims to produce fast er code or smaller code size than level 2, depending on the options used in addition to the levels, vision also has an optimize for time selection available below the optimization drop- down menu. declaring a variable as volatile will prevent the compiler from optimizing out the variable. more information on these optimization levels can be found on the keil website (http ://www.keil.co m/support/man/ docs/uv4/uv4_dg_adscc.htm). figure 11. setting the project optimization in the vision ide using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 21 and table 22 show the relative debug build sizes with the different optimization level settings. table 23 shows the coremark debug build sizes, and table 24 lis ts the coremark speed scor es for these optimization levels.
AN720 rev. 0.1 23 table 21. keil toolchain optimization comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib -o0 2068 296 24 1536 vision microlib -o0 (with optimize for time ) 2068 296 24 1536 vision microlib -o1 1704 296 20 1536 vision microlib -o1 (with optimize for time ) 1648 296 20 1536 vision microlib -o2 1616 296 20 1536 vision microlib -o2 (with optimize for time ) 1600 296 20 1536 vision microlib -o3 1604 296 20 1536 vision microlib -o3 (with optimize for time ) 1596 296 20 1536 table 22. keil toolchain optimization comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib -o0 47264 3832 5208 17972 vision microlib -o0 (with optimize for time ) 47264 3832 5208 17972 vision microlib -o1 38816 3832 5132 17952 vision microlib -o1 (with optimize for time ) 39924 3832 5132 17952 vision microlib -o2 36540 3832 5132 17952 vision microlib -o2 (with optimize for time ) 39840 3832 5132 17952 vision microlib -o3 36468 3832 5132 17952 vision microlib -o3 (with optimize for time ) 41532 3832 5132 17952
AN720 24 rev. 0.1 table 23. keil toolchain optimization comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib -o0 11276 636 156 3536 vision microlib -o0 (with optimize for time ) 11276 636 156 3536 vision microlib -o1 9788 616 140 3536 vision microlib -o1 (with optimize for time ) 10136 616 140 3536 vision microlib -o2 9640 616 140 3536 vision microlib -o2 (with optimize for time ) 10684 616 140 3536 vision microlib -o3 9680 616 140 3536 vision microlib -o3 (with optimize for time ) 11500 616 140 3536 table 24. keil toolchain optimization comparison?coremark debug speed library coremark score vision microlib -o0 coremark 1.0 : 69.402323 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o0 (with optimize for time ) coremark 1.0 : 69.402323 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o1 coremark 1.0 : 75.279256 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o1 (with optimize for time ) coremark 1.0 : 75.206352 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o2 coremark 1.0 : 74.247855 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o2 (with optimize for time ) coremark 1.0 : 87.277701 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o3 coremark 1.0 : 79.520321 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib -o3 (with optimize for time ) coremark 1.0 : 102.697150 / arm4.2 (edg gcc mode) iterations=3000 / stack
AN720 rev. 0.1 25 6.6. unused code removal each file in a project becomes an object that is included. in other words, if any functions in a file are used, then the entire file is included by default. this can become an i ssue for a project using the si32hal and only a few functions from each module. removed (unused) functions can be viewed in the map files for the projects. the unused code removal feature is not automatically enab led in the keil vision ide. to enable this feature: 1. right-click on the project_name in the project window and select options for target ?project_name? or go to project ? options for target ?project_name? . 2. select the c/c++ tab. 3. use the one elf section per function checkbox to enable or disable unused code removal. figure 12. setting the remove unused code option in the vision ide using the sim3u1xx_blinky and demo_si32usbaudio default examples in the si32hal 1.0.1 software package, table 25 and table 26 show the relative debug build sizes with different unused code removal settings. table 27 shows the coremark build sizes, and table 28 shows the coremark scores for the different unused code removal settings.
AN720 26 rev. 0.1 table 25. keil unused code removal comparison?sim3u1xx_blinky debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib with no unused code removal 1392 296 12 1536 vision microlib with unused code removal 1184 296 12 1536 table 26. keil unused code removal comparison?demo_si32usbaudio debug library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib with no unused code removal 47264 3832 5208 17972 vision microlib with unused code removal 43464 3772 5060 17780 table 27. keil unused code removal comparison?coremark debug size library code (bytes) read only data (bytes) read-write data (bytes) zero-initialized data (bytes) vision microlib with no unused code removal 11276 636 156 3536 vision microlib with unused code removal 11012 636 156 3536 table 28. keil unused code removal comparison?coremark debug speed library coremark score vision microlib with no unused code removal coremark 1.0 : 69.402324 / arm4.2 (edg gcc mode) iterations=3000 / stack vision microlib with unused code removal coremark 1.0 : 67.374626 / arm4.2 (edg gcc mode) iterations=3000 / stack
AN720 rev. 0.1 27 6.7. reset sequence the speed of the reset sequence of a device can be an important factor, especially for devices like the sim3u1xx/ sim3c1xx that require a reset to exit the lowest power mode. after the hardware jumps to the reset vector and loads the stack pointer address, the core must initialize the memory of the device. this involves copying data fr om flash to ram an d zero-filling any zero-initialized segments. then, the reset code typically calls a system initialization functi on and jumps to main. this reset sequence may take different times based on t he library used with the project. the startup code should always be compiled with the fastest speed optimizati on to ensure it takes as little time as possible. the si32hal examples have a ~500 ms delay added to a pi n reset event to prevent code from switching to a non- existent clock source and disable the device . this delay can be removed by defining the si32haloption_disable_pin_reset_delay symbol in the project. to define a symbol in keil vision: 1. right-click on the project_name in the project window and select options for target ?project_name? or go to project ? options for target ?project_name? . 2. select the c/c++ tab. 3. use the define text box to add or remove project symbols. figure 13. adding a project define symbol in the vision ide table 29 shows the reset time comparison for the toolchai n libraries using the fastest speed optimization on the start up code. this time was measured using the sim3u1xx_blinky example in debug mode from the rise of resetb to the fall of a port pin at the beginning of main() on an oscilloscope. table 29. keil toolchain library usage comparison?sim3u1xx_blinky debug reset sequence library reset time (s) vision standard 52 vision microlib 48
AN720 28 rev. 0.1 c ontact i nformation silicon laboratories inc. 400 west cesar chavez austin, tx 78701 tel: 1+(512) 416-8500 fax: 1+(512) 416-9669 toll free: 1+(877) 444-3032 please visit the silicon labs technical support web page: https://www.silabs.com/support/pages/contacttechnicalsupport.aspx and register to submit a technical support request. patent notice silicon labs invests in research and development to help our cust omers differentiate in the market with innovative low-power, s mall size, analog- intensive mixed-signal soluti ons. silicon labs' extensive pat ent portfolio is a testament to our unique approach and world-clas s engineering team. silicon laboratories and silicon labs are trademarks of silicon laboratories inc. other products or brandnames mentioned herein are trademarks or registered trademarks of their respective holders. the information in this document is believed to be accurate in all respects at the time of publication but is subject to change without notice. silicon laboratories assumes no responsibility for errors and omissions, and disclaims responsib ility for any consequences resu lting from the use of information included herein. a dditionally, silicon laboratorie s assumes no responsibility for the functioning of und escribed features or parameters. silicon laboratories reserves the right to make changes without further notice . silicon laboratories makes no wa rranty, rep- resentation or guarantee regarding the suitability of its products for any particular purpose, nor does silicon laboratories as sume any liability arising out of the application or use of any product or circuit, and s pecifically disclaims any an d all liability, including wi thout limitation conse- quential or incidental damages. silicon laborat ories products are not designed, intended, or authorized for use in applications intended to support or sustain life, or for any other application in which the failure of the silicon laboratories product could create a s ituation where per- sonal injury or death may occur. should buyer purchase or us e silicon laboratories products for any such unintended or unauthor ized ap- plication, buyer shall indemnify and hold silicon laboratories harmless against all claims and damages.

▲Up To Search▲

Price & Availability of AN720

	To Download AN720 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .